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Normalization 


Normalization refers to an optimization process of structuring a relational 
database in a way that reduces redundancy of data and improves data 
integrity and consistency. There are many different normal forms, which 
relate to the degree to which a database has been normalized. We will 
look at the first three normal forms, each of which build upon the 
previous: 


¢  1NF- must have a primary key, no repeating groups, and atomic 
columns 

¢ 2NF - must already be in 1NF, plus have no partial dependencies 

¢ 3NF - must already be in 2NF, plus have no transitive dependencies 


The first normal form enforces that a table must: 


¢ Have a primary key 
¢ Each column should be as granular as possible (e.g. "Name" 


column should be broken up into: "First Name", "Last Name", 


"Middle Name", etc..) 


To be in second normal form, a table must also: 


¢ Cannot have columns that are dependent on only one part of the 
key 
¢ If there are no composite primary keys, you are automatically in 


2NF 


Finally, to get to third normal form, a table must also: 


¢ Not have transitive dependencies 

¢ This means that if column C relates to column B which relates to 
column A which is the primary key, this is not in 3NF because C is 
related to the primary key but indirectly (it is a transitive 
dependency) 


To advance into higher normal forms, we typically "break up" tables into 
multiple tables and relate them to each other via foreign keys. 


A good way of remembering these normal forms in order is to remember 
the legal proceeding of swearing to tell the truth, the whole truth, and 


nothing but the truth. In relational databases, we must have the key 
(INF), the whole key (2NF), and nothing but the key (3NF). 


Multiplicity 


As mentioned before, table relationships can be defined using foreign 
key constraints. There are several different kinds of relationships that exist 
between tables in relational databases: 


e One to one 

¢ One to Many / Many to One 

¢ Many to Many 
A one-to-one relationship means that each entity in the table only relates 
to a single entity in the other table. For example, if we are modeling a 
school, where each classroom has a single projector in it, we would want 
to make this relationship a one to one between the Classroom and 
the Projector tables. In our database, we can provide the classroom table 
a projector_id foreign key and provide the projector table 
a classroom_id foreign key. To enforce the one to one aspect, we should 
also apply a unique constraint on the foreign key columns. Otherwise, a 
user could add another projector record with the same classroom_id as 
an existing record, and then our one to one relationship would be 
broken. 


A one to many (or vice versa, many to one) relationship is where one 
entity can belong to, own, or otherwise relate to multiple other entities. In 
our school modeling example, a Student could have many books, so this 
would be a one to many relationship. To create this in the database, we 


add the foreign key only on the many side of the relationship - so 
a book entity would have a field such as student_id as a foreign key to 
identify the owning student. 


A many-to-many relationship implies a one-to-many relationship in both 
directions on the entities. For example, a Teacher can have many 
Students, but a Student could have many Teachers as well. In this 

case, we cannot provide a direct link between the tables in the 
database - instead, we need to create what is called 

a junction table or bridge table to relate the two tables. So, in 
our student-teacher example, we could create a Class table which 
contains two foreign keys - one that refers to the Teacher table's primary 
key and one that refers to the Student table's primary key. This creates a 
list of unique Teacher-Student mappings that can be used to look up 
which students a particular teacher teaches, or which teachers a 
particular student has. An example is shown below. 
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We can see above that Teacher 1 teaches both Student 1 and 2 in the 
same class. Teacher 2 teaches Student 1 and 3 in a different class. 
Teacher 1 also has another class where he just teaches Student 3. 


Data Access Objects 


When writing JDBC code, the application business logic may get mixed in 
with JDBC boilerplate code for querying the database, resulting in hard 
to read spaghetti code. One way to address this problem is to logically 
separate the code that accesses the database into Data Access Objects - 


this is referred to as the DAO design pattern. 


To use the DAO design pattern, define an interface which declares 
methods through which the database will be queried. Then, concrete 
implementation classes can implement the interface and contain the data 
access logic to return the required data. 


For example, if we have an Employee table in our database we'd like to 
query, we would create a EmployeeDAO interface: 


public interface EmployeeDAO { 
// define some CRUD operations here 
public List<Employee> getAllEmployees(); 
public List<Employee> getEmployeesByLocation(String location); 
public void updateEmployeeByld(int id); 
public void deleteEmployeeByld(int id); 
public void addEmployee(Employee e); 
} 
This interface would be implemented for a specific database - e.g. 
Oracle: 


public class EmployeeDAOImplOracle implements EmployeeDAO { 
public List<Employee> getAllEmployees() { 
List<Employee> list = new ArrayList<>(); 
// JDBC code here... 


return list; 


}; 
public List<Employee> getEmployeesByLocation(String location) { 
List<Employee> list = new ArrayList<>(); 
// JDBC code here... 
return list; 
}; 
public void updateEmployeeByld(int id) { 
// JDBC code here... 
}; 
public void deleteEmployeeByld(int id) { 
// JDBC code here... 
}; 
public void addEmployee(Employee e) { 
// JDBC code here... 
}; 
} 
Now whenever we need to query the Employee table in the database, 
we have a simple, clean interface which abstracts the data access logic: 


EmployeeDAO dao = new EmployeeDAOImplOracle(); 

List<Employee> allEmpls = dao.getAllEmployees(); 

allEmpls.forEach( e -> System.out.println(e)); 

List<Employee> NYEmpls = dao.getEmployeesByLocation(“New York"); 
NYEmpls.forEach( e -> System.out.println(e)); 


Also, we can simply swap out the concrete 

class EmployeeDAOImplOracle for another database-specific class if we 
need to at some point in the future, since we rely only on 

the EmployeeDAO interface. The implementation doesn't even need to be 
talking to a database - it could be reading and writing to files for all we 


know! We don't care how the data is being read or written, we just 


care what operations are defined for the object. That is the benefit the 
DAO design pattern brings to the table. 


JDBC Classes and Interfaces 


JDBC stands for Java Database Connectivity. It is a relatively low-level 
API used to write Java code that interacts with relational databases via 
SQL. 


The JDBC classes and interfaces are located in 
the java.sql and javax.sqlpackages. There are several key classes and 
interfaces that are commonly encountered when writing JDBC code: 


° DriverManager class - to make a connection with a database driver 

¢ DataSource interface - for retrieving connections, an alternative 
to DriverManager 

* Connection interface - represents a physical connection with a 
database 

° SQLException class - a general exception thrown when something 
goes wrong when accessing the database 

* Statement interface - used for executing static SQL statements 

* PreparedStatement interface - represents pre-compiled SQL 
statements 

* CallableStatement interface - used to execute stored procedures 

* ResultSet interface - represents data returned from the database 

Creating a Database Connection 


In order to interact with a database, we need to do several things: 


1. Register the JDBC driver 

2. Open a connection using: 

¢ Database URL 

e Username 

¢ Password 

1. Execute some SQL statement using either: 

° Statement 

° PreparedStatement 

°  CallableStatement 

1. Retrieve the results that are returned in a ResultSet object 


JDBC Classes and Interfaces 


JDBC stands for Java Database Connectivity. It is a relatively low-level 
API used to write Java code that interacts with relational databases via 


SQL. 


The JDBC classes and interfaces are located in 
the java.sql and javax.sqlpackages. There are several key classes and 
interfaces that are commonly encountered when writing JDBC code: 


DriverManager class - to make a connection with a database driver 
DataSource interface - for retrieving connections, an alternative 
to DriverManager 

Connection interface - represents a physical connection with a 
database 

SQLException class - a general exception thrown when something 
goes wrong when accessing the database 

Statement interface - used for executing static SQL statements 
PreparedStatement interface - represents pre-compiled SQL 
statements 

CallableStatement interface - used to execute stored procedures 
ResultSet interface - represents data returned from the database 


Creating a Database Connection 


In order to interact with a database, we need to do several things: 


Register the JDBC driver 

Open a connection using: 

Database URL 

Username 

Password 

Execute some SQL statement using either: 

Statement 

PreparedStatement 

CallableStatement 

Retrieve the results that are returned in a ResultSet object 


Database JDBC Drivers 


Because JDBC is a Java language API, it is database agnostic. It uses 
database drivers which implement the interfaces defined in the JDBC API 
for the given database. For example, to connect with an Oracle 
database, you would use an OJDBC driver. Other database vendors 
have different drivers which implement the JDBC API. 


Many JDBC drivers are available through Maven's central repository and 
can be added as a dependency in the pom.xmlfile. Oracle is a special 
exception due to license restrictions. You must accept the license 
agreement, download, and install it to your local Maven repository 
before you can add it to the pom.xml file. 


Finally, in your application code, you can register the driver using: 


try { 
Class.forName("oracle.jdbc.driver.OracleDriver"); 


catch(ClassNotFoundException e) { 

System.out.println("Can't load driver class!"); 
} 
This step is only necessary for drivers prior to JDBC 4.0 (released with 
Java SE 6). After JDBC 4.0, drivers will be auto loaded if they are 
included in the classpath. 


Connection Interface 


java.sql.Connection interface represents a session between java 
application and database. All SQL statements are executed and results 
are returned with in the context of a Connection object. 


We can use the DriverManager class to get a Connection to the 
database, given that we have the JOBC URL, username, and password. 
Generally these parameters should be stored in an external configuration 


file that can be loaded dynamically and changed without affecting the 
application code. 


try (Connection conn = 

DriverManager.getConnection(DB_URL, USERNAME,PASSWORD)) { 
// more code goes here 

} catch (SQLException e) {} 

Alternatively, the DataSource interface could be used to make 

connections. 


It's always a good idea to close your resources - here we've used the try- 
with-resources syntax to automatically close the Connection being 
created after the block ends. 


Autocommit mode 


By default, when a connection is created it is in auto-commit mode, so 
every SQL statement acts as a transaction and is committed immediately 
after execution. In order to manually group statements into a transaction, 
simply call: 


Connection conn = 

DriverManager.getConnection(DB_URL, USERNAME,PASSWORD),; 
conn.setAutoCommit(false); 

// execute some SQL statements... 

con.commit(); 


JDBC String 

The database URL is an address pointing to the database to be used, 
also known as the JDBC String. The format of this URL varies between 
database vendors, as shown in the table below: 


RDB JDBC driver URL format 
MS 


MyS  com.mysql.jdbc.Driver jdbc:mysql://hostname/ 
QL databaseName 


Orac] Ooracle.jdbc.driver.Orac 
leDriver 


SQL com.microsoft.sqlserver 
idbe SOLServerDriver 


Postg org.postgresql.Driver 


jdbc:oracle:thin:@hostname:p 
ortNumber:databaseName 


jdbc:sqlserver:// 
serverName:portNumber;prop 
erty=value 


The effective application of normalization, alongside structured data 
access methods like DAO and JDBC, forms the backbone of robust, 
scalable, and maintainable database systems in modern software 


development. 
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